Hadoop in the Enterprise: Architecture, 1st Edition by Unknown

Author:Unknown
Language: eng
Format: epub, mobi, pdf
Published: 0101-01-01T00:00:00+00:00

Quorums

During our excursion through Hadoop high availability, we will encounter the

concept of a quorum. When dealing with distributed systems, a common

problem is how to ensure that processes running on different machines agree

on the value of something in the presence of faults and failures, the so-called

problem of consensus. There has been a lot written in the literature about how

to achieve distributed consensus: you may have heard of algorithms such as

Paxos, Raft and ZooKeeper’s very own Zab. We will not go into detail about how these algorithms work here but the enterprise architect should be familiar

with the basics.

Note

If the reader is interested in this topic in detail, the “Distributed Systems”

section of Martin Kleppmann’s Designing Data-Intensive Applications is highly recommended.

In general, in order to achieve consensus in distributed systems and for that

system to support consistency (i.e. everyone is guaranteed to agree on the same

value either immediately or at some point in the future), a majority of machines

in a quorum need to agree on a value using one of the algorithms mentioned

above a the majority of machines needs to be maintained for the system to be

considered consistent.

What this all means in practice is that a quorum should consist of an odd

number of machines and that the maximum number of node failures in a quorum

of n nodes for it to remain operational is

. While

quorums can have even numbers, it would not increase the resiliency: quorums

of both 5 and 6 nodes can tolerate only 2 node failures.

In Hadoop, achieving consensus between master services is key to enabling

consistent writes and reads of metadata and are critical to services such as

ZooKeeper and HDFS HA. As we will see, other services rely on ZooKeeper

and its reliable consensus for distributed locking and configuration storage.

Load Balancing

A key requirement in any high availability setup is the ability to seamlessly and

automatically switch between instances of a service running on different nodes.

This is especially important for services which have no inbuilt mechanism for

providing HA. As clients we want some or all of the following:

To access a service via a single logical endpoint

To ultimately connect to an instance that is running and healthy

To transparently open and maintain sessions with the service

To connect to a node that is not overwhelmed with users

To automatically switch between backend service providers in the event

of failure

Step in load balancing. Load balancers act as a proxy in front of a service and,

depending on the implementation, address one or more of the above

requirements. So what are the different forms of load balancing we can use?

DNS Round Robin

The easiest form of load balancing to achieve is DNS round robin2. When clients connect to a network service they first lookup the IP address from the

DNS server (or its own local definitions) using the service hostname. DNS

servers can be configured to cycle through or return a random entry from a list

of configured IP addresses. The process is illustrated in Figure Figure 3-1:

clients query the DNS server for the IP for a hostname (1), the server response

with one of the list of configured IPs (2) and the client contacts the supplied IP

(3).

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.